1. Technical Field
The present invention relates in general to a method and system for retrieving and setting set structured data through the Internet. More particularly, the present invention relates to a system and method using Java and XML to manage LDAP data sources.
2. Description of the Related Art
Companies and other organizations are increasingly turning to computer networks, especially the Internet, for distributed applications. Applications, in turn, are often driven by data. This data can be stored in a variety of formats. Flat files can be used, however they provide little support in managing data files, especially as the application data files become large. Traditional database management systems (DBMS), such as a relational or hierarchical database can be used. An example of a relational database is IBM""s DB2(trademark) product and an example of a hierarchical database is IBM""s IMS(trademark) database product. While a DBMS is excellent at storing and retrieving data and has rich access methods, including use of a Structured Query Language (SQL), a DBMS is not always the right choice when dealing with large distributed systems where speed is often a critical factor and client computing resources are often limited. An emerging protocol for managing data is the Directory Access Protocol (DAP). Directory services, such as DAP, are fast becoming the key to many organizations, allowing applications to locate the resources they need and enabling network administrators to authenticate end-users.
DAP runs over the OSI (Open System Interconnection) network protocol stackxe2x80x94that, combined with its rich data model and operation set makes it somewhat cumbersome and difficult to implement a full-blown DAP client and have it installed on smaller computer systems. X.500 is an overall model for Directory Services in the OSI environment. The model encompasses the overall namespace and the protocol for querying and updating it.
In response to DAP""s shortcomings, LDAP, or xe2x80x9cLightweight Directory Access Protocolxe2x80x9d was developed. LDAP is, like X.500, both an information model and a protocol for querying and manipulating stored data. LDAP""s overall data and namespace model is essentially that of X.500. The major difference is that the LDAP protocol itself is designed to run directly over the TCP/IP stack, and it lacks some of the more esoteric DAP protocol functions.
A major part of X.500 is that it defines a global directory structure. It is essentially a directory Web in much the same way that HTTP and HTML are used to define and implement the global hypertext Web. Anyone with an X.500 or LDAP client may examine the global directory just as they can use a Web browser to examine the global Web.
LDAP is not a replacement for traditional database management systems and is not a substitute for a file system, nor is it a replacement for domain name servers (DNS).
LDAP was initially a low-cost, PC-based front-end for accessing X.500 directories. When the ISO standard proved too cumbersome and overhead-intensive to be widely adopted, LDAP emerged to fill the gap, expanding its original role. The IETF (Internet Engineering Task Force) specification rapidly became the solution of choice for all types of directory services applications on networks using the Internet protocol (IP).
LDAP applications can be loosely grouped into four categories: those that locate network users and resources, those that manage them, those that authenticate and secure them, and any other application that manages data but, for one reason or another, does not use a traditional DBMS. LDAP can save companies time and money. It can help network managers keep pace with the rising demand for directory services. New applications appear every day, but there are currently limits to what the protocol can do for distributed computing. For example, traditional LDAP solutions cannot store all the types of information used by network applications.
The current LDAP specification includes eight features and functions for defining or performing directory-related tasks, such as data storage and retrieval. LDAP uses an information model organized according to collections of attributes and values, known as entries. This model defines what kinds of data can be stored and how the data behaves. For example, a directory entry representing a person named xe2x80x9cJohn Doexe2x80x9d might have an attribute called sn (surname) with a value of xe2x80x9cDoexe2x80x9d. The information model, inherited almost unchanged from X.500, is extensible almostxe2x80x94any kind of new information can be added to a directory.
The LDAP schema defines the actual data elements that can be stored in a particular server and how they relate to real-world objects. Collections of values and attributes-representing objects such as countries, organizations, people, and groups are defined in the standard, and individual servers can define new schema elements as well.
The LDAP naming model specifies how information is organized and referenced. LDAP names are hierarchical; individual names are composed of attributes and values from the corresponding entry. The top entry typically represents a domain name, company, state, or organization. Entries for subdomains, branch offices or departments come next, often followed by common name (cn) entries for individuals. Like the LDAP information model, the naming model is derived directly from X.500. Unlike X.500, LDAP does not constrain the format of the namespace; it allows a variety of flexible schemes.
The LDAP security model determines how information is secured against unauthorized access. Extensible authentication allows clients and servers to prove their identity to one another. Confidentiality and integrity also can be implemented, safeguarding the privacy of information and protecting against active attacks like connection hijacking.
The LDAP functional model determines how clients access and update information in an LDAP directory, as well as how data can be manipulated. LDAP offers nine basic functional operations: add, delete, modify, bind, unbind, search, compare, modify DN (distinguished name), and abandon. Add, delete, and modify govern changes to directory entries. Bind and unbind enable and terminate the exchange of authentication information between LDAP clients and server, granting or denying end-users access to specific directories. Search locates specific users or services in the directory tree. Compare allows client apps to test the accuracy of specific values or information using entries in the LDAP directory. Modify DN makes it possible to change the name of an entry. Abandon allows a client application to tell the directory server to drop an operation in progress.
The LDAP protocol defines how all of the preceding models and functions map onto TCP/IP (Transmission Control Protocol/Internet Protocol). The LDAP protocol specifies the interaction between clients and servers and determines how LDAP requests and responses are xe2x80x9cformedxe2x80x9d (the structure of the data on the transmission path). For example, the LDAP protocol stipulates that each LDAP request is carried in a common message format and that entries contained in response to a search request are transported in separate messages, thus allowing the streaming of large result sets.
The LDAP application program interface (API) details how software programs access the directory, supplying a standard set of function calls and definitions. This API is widely used on major development platforms running C/C++, Java, Javascript, and Perl (among others).
The LDAP data interchange format (LDIF) provides a simple text format for representing entries and changes to those entries. This ability helps synchronize LDAP directories with X.500 and proprietary directories (or a company""s HR directory, which is often a source of useful information).
LDAP describes what a directory looks like and how it acts from a client""s point of view. However, the directory itself can be distributed across many servers. Each of these servers can maintain a version of the entire directory, which is replicated periodically so that all servers can determine where data is located. An LDAP server that receives a request from an application takes responsibility for the request. It may pass the request to other servers until it can be fulfilled, or it may refer the client to other servers.
Replication of directory data is also required for high availability networks. Consider a directory supplying the authentication database for a business-critical Web application. If the directory is down, the Web application cannot authenticate users, which results in lost business. One way to reduce the risk is to make two or more copies of the directory data, each served by a separate machine. If one copy becomes inaccessible, the other can take over.
Another challenge with LDAP is standard access control. LDAP currently offers a standard way for servers and clients to authenticate each other (via the bind operation). However, there is no standard way to use this information to control access to specific directory data. Thus, there is no standard way for LDAP to ensure that each database replica follows the same rules for access control.
The LDAP schema itself faces various challenges. LDAP defines basic elements for a number of fundamental applications (such as white pages, e-mail, and user and group management). However, as directories become increasingly prevalent and the number of applications relying on them increases, there is a corresponding need for new schema.
While it""s not possible to describe all of LDAP""s uses, a representative sampling conveys an idea of its versatility. LDAP location applications are becoming widespread. In this capacity, LDAP directories play the role of network-accessible database, organizing and indexing information. For example, the address book in many e-mail clients employs LDAP to locate addresses. Every time a user browses the member directory at a Web site, or a consumer scans the bestseller lists of an online bookstore, an LDAP directory is probably being used behind the scenes.
A simple but compelling example of LDAP""s value as resource locator is the online corporate phone directory. Because many corporate directories are updated regularlyxe2x80x94often by users themselvesxe2x80x94an online phone directory increases the accuracy of available information. In addition, by eliminating costly printing, an online corporate phone directory can save a large corporation thousands of dollars a year.
LDAP also plays a critical role in network management, where it can be quite useful to system administrators. Without LDAP, corporate network administrators have to maintain duplicate user information in several of application-specific directories across the network. With LDAP, it""s possible to centralize this information in a single directory accessed by all applications
Manufacturing companies with many suppliers or branch offices can use LDAP directories to deploy Web-based applications that integrate sales, inventory, and delivery processes. One repositoryxe2x80x94which can even be shared among different companiesxe2x80x94eliminates the need for separate directories and complicated synchronization.
LDAP also plays an important role in providing security, with the directory acting as gatekeeper and deciding which user has access to various resources. In this capacity, LDAP performs two critical jobs. First, it serves as an authentication database. Second, once the identity of a user has been established, it controls access to resources, applications, and services (using stored policies and other information).
LDAP also permits corporate network administrators to use directories to implement PKI (public key infrastructure) security. From the user""s point of view, LDAP provides the directory in which the certificates of other users are found, enabling secure communication. From the administrator""s point of view, LDAP directories are the way in which certificates can be centrally deployed and managed.
While LDAP data stores are useful, they present certain challenges when dealing with a client computer system. Client computer systems primarily use Web browsers to display text. This text is often formatted using a language, such as the Hypertext Markup Language (HTML) that is interpreted by the client""s Web browser. Web browsers often handle text well, yet have difficulty handling other types of data such as integers, floating point data, and other data types. In addition, Web browsers contain little inherent ability to handle or manage LDAP data stores.
What is needed, therefore, is a way to receive textual information from a client computer system and store it in an LDAP data store with a particular data type. In addition, what is needed is a flexible way to retrieve typed data from an LDAP data store and return the data to a client as textual information.
It has been discovered that managing distributed data stores, such as databases and directories, can be improved using a layered approach that provides a unique interface to the data store. The layers included in the approach include a client handling layer, a data conversion layer, and a data store interface layer.
The client handling layer receives requests from clients over a computer network, such as the Internet. In one embodiment, the client handling layer includes a browser servlet. The browser servlet receives requests from clients, such as users using a browser on a personal computer connected to the Internet. The browser servlet builds a document describing the data being requested or stored by the client. In one embodiment, the document includes an Extensible Markup Language (XML) document and includes information about the field name, the action to take on the data field, the type of data, and a textual representation of a data value (if the data value is being stored by the client). The document describing the data is passed to the data conversion layer for further processing.
The data conversion layer receives the document describing the data, determines the action to perform on the data, and identifies and invokes a process to perform the action. In one embodiment, the data conversion layer includes an XML servlet layer that processes an XML document received from the browser servlet layer. In the XML servlet, reflection is used to locate a method for handling the data. In this embodiment, methods are named according to the function they perform and the data field they operate against. For example, a method to retrieve a field named address is named xe2x80x9cgetAddressxe2x80x9d and the method used to store an address is named xe2x80x9csetAddressxe2x80x9d. A xe2x80x9cgetxe2x80x9d and a xe2x80x9csetxe2x80x9d method exist for all fields that the client can retrieve or store in the data store. In one embodiment, Java xe2x80x9creflectionxe2x80x9d is used to identify a matching method. The data conversion layer passes the request to a data store interface layer where the data is retrieved or stored as requested by the client.
The data store interface layer includes procedures for storing and retrieving data from the data store. In one embodiment, the data store includes a Lightweight Directory Access Protocol (LDAP) storage area. The data store interface layer, referred to as an LDAP Interface Layer, performs actions on the data by performing methods used to get and set fields. In this embodiment, when a field is being retrieved, it is stored as a Java object that is returned to the XML servlet layer. The XML servlet layer determines how to convert the returned Java object to a text string. The text string is stored in an XML document that is returned to the client handling layer (browser servlet layer). The browser servlet layer uses the data contained in the XML document to prepare a page to return to the client. In one embodiment, a Hypertext Markup Language (HTML) document is prepared that is sent to the client. The HTML document is displayed on the client""s computer system using standard browser software.
The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.